The protection showed above is obviously an easy scheme to get around, and to
tell you the truth, there really aren’t that many hard schemes on the Mac, like
there are or were on the Apple II. It is important to check the routine you are
disabling. Sometimes variables (or globals) are passed in between different parts
of protection schemes, if you skip the entire protection scheme there is a pretty
good chance you will miss a variable (or global) getting passed and your program
will crash on you in the future.
The best way to check is to use the program after you have initially deprotected
it, if it works ok, then chances are no globals were passed. In the example
above, all of the globals were passed in the prior two JSRs, which made things
very easy.
Chapter 5 - Serial Number Schemes
Serial Number Protection Schemes are the same as Password Protection Schemes in
most cases. Both are checked with memory using a compare instruction, but they do
have differences. For example, certain serial number schemes are actually
mathematical answers where the application will perform some complex arithmetic
equation using such information as your name or company name, if the equations
solution matches the serial number you type in the program will continue on like
normal.
Some serial number schemes are easy and do not use any arithmetic all, some check
to see if you enter a prime number, etc. There are many ways. Probably the most
common is; the company making the software will add a resource to the application
housing the serial number. When the package first loads, it will ask you for your
serial number then will do a compare with the value entered and the value stored
in the serial number resource.
Chapter 6- Key Disk Protection Schemes
There are a couple of different ways commercial software authors implement Key
Disk Protection. Key disk protection essentially is software that requires the
original floppy diskettes to run correctly. These types of programs come with an
installer for copying them onto a hard drive. Some packages offer three installs
to a hard drive; if you need more copies, you have to use the original disk each
time you run that program.
Essentially what is happening here is this. On the floppy disk there are files
with their INVISIBLE bit set meaning they will not bee seen or accounted for in
the volume info. Therefore, if you try to copy the program onto a hard drive the
invisible files will not be copied and the copy will not work properly. If you
just turn the INVISIBILITY bit off using ResEdit and then copy the files, the
program will work. But, this is only for programs that do not always need the key
disk. Other programs require the key disk every time you run the application. In
those cases, the key disk has a purposely bad block. When you run the
application, it will read from the floppy and test the block’s status. If it is
bad it will continue on knowing it is the original disk, it the block is ok it
means that the program has been copied onto another disk which is not the
original or key disk. The best way to operate around this scheme is to trace
through the program to where it actually reads from the floppy, then change the
BRANCH condition after the COMPARE. This will fool the program into always
thinking that the block that is read is bad.
Chapter 7- Date Expiration Schemes
These schemes occur out of the blue without notice most of the time. Most apps
that use this scheme are beta apps that are expected to be updated before too
long or demos of games and such. There are only two ways to read the current date
or time on a Macintosh, one is to use the _GetDateTime trap the other is to use
the Macintosh Global variable memory address $020C at which the current number of
seconds that has elapsed since Midnight, January 1st is stored. Basically both
routines are extremely similar and would probably look something like this:
_GetDateTime (Protection Method)
_GetDateTime (Get current # of secs since 12am 01/01/04)
CMPI.L expiredate,D1 (Compare the date with expiration date)
BLE notexpired (If less than, then it hasn't expired)
JSR EXPIRED! (Otherwise show the dialog and bomb out!)
Address $020C (Protection Method)
CMPI.L expiredate,$020C (Compare the current date with expire date)
BGT EXPIRED (If current date is > then expire date,
show dialog
& BOMB!)
--------- (otherwise it hasn't expired and
everything is
ok!)
That should have given you some idea what the protection schemes look like, they
vary of course but that is what they will normally be like. The simple way to
disarm these routines is to change the Branch Condition, for instance in the
first protection scheme shown above it would be extremely easy to change the BLE
to a BRA which will automatically branch to the “notexpired” portion of the
program.
For the second routine has an easy way to eliminate the protection scheme. It
would be to change the 'BGT EXPIRED' into two NOPs. Which will totally eliminate
the check and fool the program into thinking everything is ok.
Chapter 8- Hardware Key Protection
Not many people know too much about this protection scheme. But one obvious
observation is that companies are making there own devices and confused companies
with low marketshare are buying into there hardware protection scheme, which
really is not that good to tell you the truth.
Basically what the Eve‚Ñ¢ hardware key does is it hooks up to your ADB port and
has a chip in it which can be read from. All of the packages I have seen that use
the Eve‚Ñ¢ protection key come with an Eve INIT. Basically this INIT reads one or
more values from the Eve key and stores it somewhere in memory. The program that
will then do a Compare to the memory to see if the values match if they do then
the program will continue, however if there is a null value found the program
will warn you that the Eve Key is not present and then quit. If the value is
incorrect it will tell you that you either have the Eve hooked up incorrectly or
that you are using an Eve from a different software package.
The easiest way around the Eve Hardware key would be to change the Branch
conditions of the checks it does 1) to locate Eve and 2) to compare the values.
Once you have changed these branch conditions the program will work as it would
have if the Eve protection had not been implemented.
From what I have heard some software locations or other important data to the
program is stored in the Eve‚Ñ¢ that may be needed upon run time. For example, if
a program is encrypted and the decryption routine is stored on the Eve‚Ñ¢ key it
would be almost impossible to deprotect the program without a valid Eve‚Ñ¢ key to
work with.
So, I would just use MacsBug the way we have been and just trace through for the
checks. Eve‚Ñ¢ will let you know when something is wrong through the use of
dialogs, so tracing is pretty easy. Find those branches and change the
conditions.
Chapter 9- The Ultimate Protection Scheme
This is a hotly debated topic. Most people would say that no protection scheme
can go uncracked, but I beg to differ. I am sure I can stir something up that
will boggle a few minds for at least 6 months of everyday tracing. Which will
probably force that cracker to stop working on it.
In this day and age all software should be unprotected and should be available
through the Shareware system. Corporate America is crippling our economy and the
only ones benefitting from it are the few 'elite' businessmen or businesswomen.
The Shareware system ensures that the people/programmers who put their time and
effort into their projects recieve all of the money they bring in. Thats what
Corporate America should be like. Spread the wealth amongst everyone. And work
for the money you make, don’t cheat anyone out of it.
'This article is written in memory of the old apple pirates who have paved the
way for a new breed of "elite pirate" life form. Hadn't it been for their
patience and instruction our generation of pirates would have died off long ago.
Now I pass onto you my knowledge and ideas in hope that you will all use it,
share it, work together with it and be "elite" toward one another. '
The Vassal
Many thanks to: Hipcheck, Agent Orange, The Terrorist and HackMan
Also thanks to: Far Side, Jim Heebner, Zelig, ShadowMan, The Embalmer, Mr_T, The Wahoo, Grimm, Enigmatic Simplicity, Gandalf Greyhame, and (High Voltage for reminding me what the Apple II days were really like)...
